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Q Abstract 

Cn i; Generic programming (GP) is an increasingly important trend in 
programming languages. Well-known GP mechanisms, such as 

■ >. ■ ■ type classes and the C++Ox concepts proposal, usually combine 

l~~l ' two features: 1) a special type of interfaces; and 2) implicit instan- 

^^ , nation of implementations of those interfaces. 

^ • Scala implicits are a GP language mechanism, inspired by type 

^ ■ classes, that break with the tradition of coupling implicit instantia- 
tion with a special type of interface. Instead, implicits provide only 
implicit instantiation, which is generalized to work for any types. 

^"^ • This turns out to be quite powerful and useful to address many lim- 

^ ' itations that show up in other GP mechanisms. 
O" ' This paper synthesizes the key ideas of implicits formally in 

Q/ , a minimal and general core calculus called the implicit calculus 

\l . (A=>), and it shows how to build source languages supporting im- 

\l plicit instantiation on top of it. A novelty of the calculus is its sup- 

f»f-\ port for partial resolution and higher-order rules (a feature that has 

f^ , been proposed before, but was never formalized or implemented). 

^vj B Ultimately, the implicit calculus provides a formal model of implic- 

I ■ its, which can be used by language designers to study and inform 

• • ■ implementations of similar mechanisms in their own languages. 

> ' 
• i-H ' Categories and Subject Descriptors D.3.2 [Programming Lan- 

J^ , guages]: Language Classifications — Functional Languages, Object- 

$_( . Oriented Languages; F.3. 3 [Logics and Meanings of Programs]: 

Cu • Studies of Program Constructs 

General Terms Languages 

Keywords Implicit parameters, type classes, C-l~l- concepts, generic 
programming, Haskell, Scala. 

1. Introduction 

Generic programming (GP) 1231 is a programming style that de- 
couples algorithms from the concrete types on which they oper- 
ate. Decoupling is achieved through parametrization. Typical forms 
of parametrization include parametrization by type (for example: 
parametric polymorphism, generics or templates) or parametriza- 
tion by algebraic structures (such as a monoid or a group). 

A central idea in generic programming is implicit instantia- 
tion of generic parameters. Implicit instantiation means that, when 
generic algorithms are called with concrete arguments, the generic 
arguments (concrete types, algebraic structures, or some other form 
of generic parameters) are automatically determined by the com- 
piler. The benefit is that generic algorithms become as easy to use 



as specialized algorithms. To illustrate implicit instantiation and its 
benefits consider a polymorphic sorting function: 

sort [a] : (a — >■ a — !■ Bool) — >■ List a — >■ List a 

with 3 parameters: the type of the elements in the list (a); the 
comparison operator; and the list to be compared. Instantiating 
all 3 parameters explicitly at every use of sort would be quite 
tedious. It is likely that, for a given type, the sorting function is 
called with the same, explicitly passed, comparison function over 
and over again. Moreover it is easy to infer the type parameter a. 
GP greatly simplifies such calls by making the type argument and 
the comparison operator implicit. 

isort : VQ.(a — >■ a — )> Bool) => List a — s- List a 

The function isort declares that the comparison function is implicit 
by using => instead of — S-. It is used as: 

implicit {cmpint : Int -^ Int — > Bool} in 

(4sori[2, 1,3], isori [5, 9,3]) 

The two calls of isort each take only one explicit argument: the list 
to be sorted. Both the concrete type of the elements (Int) and the 
comparison operator ( cmpint) are implicitly instantiated. 

The element type is automatically infen^ed from the type of 
the list. More interestingly, the implicit comparison operator is 
automatically determined in a process called resolution. Resolution 
is a type-directed process that uses a set of rules, the implicit 
environment, to find a value that matches the type required by 
the function call. The implicit construct extends the implicit 
environment with new rules. In other words, implicit is a scoping 
construct for rules similar to a conventional let-binding. Thus, in 
the subexpression [isort [2, 1, 3], isort [5, 9, 3]), cmpint is in the 
local scope and available for resolution. 

1.1 Existing Approaches to Generic Programming 

The two main strongholds of GP are the C-l~l- and the functional 
programming (FP) communities. Many of the pillars of GP are 
based on the ideas promoted by Musser and Stepanov 1123 1 . These 
ideas were used in C-l~l- libraries such as the Standard Template 
Library 11241 and Boost fTj. In the FP community, Haskell type 
classes 1421 have proven to be an excellent mechanism for GP, 
although their original design did not have that purpose. As years 
passed the FP community created its own forms of GP 114111011271 . 
Garcia et al.'s (9) comparative study of programming language 
support for GP was an important milestone for both communi- 



ties. According to tliat study many languages provide some sup- 
port for GP. However, Haskell did particularly well, largely due to 
type classes. A direct consequence of that work was to bring the 
two main lines of work on GP closer together and promote cross - 
pollination of ideas. Haskell adopted associated types |4l|3], which 
was the only weak point found in the original comparison. For the 
C++ community, type classes presented an inspiration for develop- 
ing language support for concepts 123111111341 . 

Several researchers started working on various approaches to 
concepts (see Siek's work 1331 for a historical overview). Some re- 
searchers focused on integrating concepts into C++ ||7] |11I . while 
others focused on developing new languages with GP in mind. 
The work on System F 1341 1351 is an example of the latter ap- 
proach: Building on the experience from the C++ generic program- 
ming community and some of the ideas of type classes, Siek and 
Lumsdaine developed a simple core calculus based on System F 
which integrates concepts and improves on type classes in several 
respects. In particular. System F'~' supports scoping of ruleo 

During the same period Scala emerged as new contender in the 
area of generic programming. Much like Haskell, Scala was not 
originally developed with generic programming in mind. However 
Scala included an alternative to type classes: implicits. Implicits 
were initially viewed as a poor man's type classes 1261 . Yet, ulti- 
mately, they proved to be quite flexible and in some ways superior 
to type classes. In fact Scala turns out to have very good support 
for generic programming II281I29I . 

A distinguishing feature of Scala implicits, and a reason for 
their power, is that resolution works for any type. This allows Scala 
to simply reuse standard OO interfaces/classes (which are regular 
types) to model concepts, and avoids introducing another type of 
interface in the language. In contrast, with type classes, or the 
various concept proposals, resolution is tightly coupled with the 
type class or concept-like interfaces. 

1.2 Limitations of Existing Meclianisms 

Twenty years of programming experience with type classes gave 
the FP community insights about the limitations of type classes. 
Some of these limitations were addressed by concept proposals. 
Other limitations were solved by implicits. However, as far as we 
know, no existing language or language proposal overcomes all 
limitations. We discuss these limitations next. 

Global scoping: In Haskell, rulejj are global and there can be 
only a single rule for any given type III8l l2ll6ll8l. Locally scoped 
rules are not available. Several researchers have already proposed to 
fix this issue: with named rules III8I or locally scoped ones l|2ll6l[8l. 
However none of those proposals have been adopted. 

Both proposals for concepts and Scala implicits offer scoping of 
rules and as such do not suffer from this limitation. 

Second class interfaces: Haskell type classes are second-class 
constructs compared to regular types: in Haskell, it is not possible 
to abstract over a type class III3I . Yet, the need for first-class 
type classes is real in practice. For example, Lammel and Peyton 
Jones I2II desire the following type class for their GP approach: 



class {Typeable a, cxt a) => 
gmapQ :: (y (3. Data cxt /3 



Data cxt a where 

4> /3 — ^ r) ^« Q — )> [r 



In this type class, the intention is that the ctx variable abstracts 
over a concrete type class. Unfortunately, Haskell does not support 
type class abstraction. Proposals for concepts inherit this limitation 
from type classes. Concepts and type classes are usually interpreted 
as predicates on types rather than types, and cannot be abstracted 



In the context of C++ rules conespond to models or conceptjnaps. 
- In the context of Haskell rales correspond to type-class instances. 



over as regular types. In contrast, because in Scala concepts are 
modeled with types, it is possible to abstract over concepts. Oliveira 
and Gibbons |28) show how to encode this example in Scala. 

No higher-order rules: Finally type classes do not support 
higher-order rules. As noted by Hinze and Peyton Jones |12], non- 
regular Haskell datatypes like: 

data Perfect f a = Nil \ Cons a {Perfect f (fa)) 

require type class instances such as: 

instance {yp.Show /3 => Show (/ j3), Show a) => 
Show [Perfect f a) 

which Haskell does not support, as it restricts instances (or rules) to 
be first-order. This rule is higher-order because it assumes another 
rule, Wp.Show (3 => Show (f /3), that contains an assumption 
itself. Also note that this assumed rule is polymorphic in l3. 

Both concept proposals and Scala implicits inherit the limitation 
of first-order rules. 

1.3 Contributions 

This paper presents A=^, a minimal and general core calculus for 
implicits and it shows how to build a source language supporting 
implicit instantiation on top of it. Perhaps surprisingly the core 
calculus itself does not provide implicit instantiation: instantia- 
tion of generic arguments is explicit. Instead A=i. provides two key 
mechanisms for generic programming: 1) a type-directed resolution 
mechanism and 2) scoping constructs for rules. Implicit instantia- 
tion is then built as a convenience mechanism on top of A^ by com- 
bining type-directed resolution with conventional type-inference. 
We illustrate this on a simple, but quite expressive source language. 

The calculus is inspired by Scala implicits and it synthesizes 
core ideas of that mechanism formally. In particular, like Scala 
implicits, a key idea is that resolution and implicit instantiation 
work for any type. This allows those mechanisms to be more widely 
useful and applicable, since they can be used with other types in 
the language. The calculus is also closely related to System F , 
and like System F , rules available in the implicit environment 
are lexically scoped and scopes can be nested. 

A novelty of our calculus is its support for partial resolution and 
higher-order rules. Although Hinze and Peyton Jones III2I have dis- 
cussed higher-order rules infomially and several other researchers 
noted their usefulness |40 30 28 1, no existing language or calculus 
provides support for them. Higher-order rules are just the analogue 
of higher-order functions in the implicits world. They arise natu- 
rally once we take the view that resolution should work for any 
type. Partial resolution adds additional expressive power and it is 
especially useful in the presence of higher-order rules. 

From the GP perspective A=^ offers a new foundation for 
generic programming. The relation between the implicit calculus 
and Scala implicits is comparable to the relation between System 
F'^ and various concept proposals; or the relation between formal 
calculi of type classes and Haskell type classes: The implicit calcu- 
lus is a minimal and general model of implicits useful for language 
designers wishing to study and inform implementations of similar 
GP mechanisms in their own languages. 

In summary, our contributions are as follows. 

• Our implicit calculus A=^ provides a simple, expressive and 
general formal model for implicits. Despite its expressiveness, 
the calculus is minimal and provides an ideal setting for the 
formal study of implicits and GP. 

• Of particular interest is our resolution mechanism, which is 
significantly more expressive than existing mechanisms in the 
literature. It is based on a simple (logic-programming style) 



query language, works for any type, and it supports partial 
resolution as well as higher-order rules. 

• The calculus has a polymorphic type system and an elaboration 
semantics to System F. This also provides an effective imple- 
mentation of our calculus. The elaboration semantics is proved 
to be type-preserving, ensuring the soundness of the calculus. 

• We present a small, but realistic source language, built on top 
of A=> via a type-directed encoding. This language features 
implicit instantiation and a simple type of interface, which 
can be used to model simple forms of concepts. This source 
language also supports higher-order rules. 

• Finally, both A^ and the source language have been imple- 
mented and the source code for their implementation is avail- 
able at |http://ropas.siiu.ac.kr/~bruiio/implicit[ 

Organization Section 2 presents an informal overview of our cal- 
culus. Section 3 shows a polymorphic type system that statically 
excludes ill-behaved programs. Section 4 shows the elaboration 
semantics of our calculus into System F and coiTectness results. 
Section 5 presents the source language and its encoding into A^ . 
Section 6 discusses comparisons and related work. Section 7 con- 
cludes. 

2. Overview of the Implicit Calculus A=^ 

Our calculus A=> combines standard scoping mechanisms (abstrac- 
tions and applications) and types a la System F, with a logic- 
programming-style query language. At the heart of the language 
is a threefold interpretation of types: 

types = propositions = rules 

Firstly, types have their traditional meaning of classifying terms. 
Secondly, via the Cuiiy-Howard isomorphism, types can also be 
interpreted as propositions ~ in the context of GP, the type proposi- 
tion denotes the availability in the implicit environment of a value 
of the corresponding type. Thirdly, a type is interpreted as a logic- 
programming style rule, i.e., a Prolog rule or Horn clause Hi 91 . Res- 
olution [20j connects rules and propositions: it is the means to show 
(the evidence) that a proposition is entailed by a set of rules. 

Next we present the key features of A^ and how these features 
are used for GP. For readability purposes we sometimes omit re- 
dundant type annotations and slightly simplify the syntax. 

Fetching values by types: A central construct in A^ is a query. 
Queries allow values to be fetched by type, not by name. For 
example, in the following function call 

foo lint 

the query lint looks up a value of type Int in the implicit environ- 
ment, to serve as an actual argument. 

Constructing values with type-directed rules: A=j. constructs 
values, using programmer-defined, type-directed rules (similar to 
functions). A rule (or rule abstraction) defines how to compute, 
from implicit arguments, a value of a particular type. For example, 
here is a rule that computes an Int x Bool pair from implicit Int 
and Bool values: 

(|(?/ni -I- 1, -. IBool) : {Int, Bool} ^ IntxBool\) 

The rule abstraction syntax resembles a type- annotated expression: 
the expression (lInt + 1, -i IBool) to the left of the colon is the rule 
body, and to the right is the rule type { Int, Bool } => Int x Bool. 
A rule abstraction abstracts over a set of implicit values (here 
{Int, Bool }), or, more generally, over rules to build values. 

Hence, when a value of type Int x Bool is needed (expressed 
by the query l[Int x Bool)), the above rule can be used, provided 



that an integer and a boolean value are available in the implicit 
environment. In such an environment, the rule returns a pair of the 
incremented Int value and negated Bool value. 

The implicit environment is extended through rule application 
(analogous to extending the environment with function applica- 
tions). Rule application is expressed as, for example: 

(\[llnt + l,^ IBool) : {Int, Bool} ^ IntxBool\j 
v^ith {1, True} 

With syntactic sugar similar to a let-expression, a rule abstraction- 
application combination is denoted more compactly as: 

implicit {1, True} in {lint + 1,^ IBool) 

which returns (2, False). 

Higher-order rules: A=^ supports higher-order rules. For exam- 
ple, the rule 

(|?(/ni X Int) : {Int, {Int} => Int xint} ^ Int x Int\), 

when applied, will compute an integer pair given an integer and 
a rule to compute an integer pair from an integer. Hence, the 
following rule appUcation returns (3, 4): 

implicit {3, (\{llnt, lint + 1) : {Int} ^ Int x Int\) } in 
l{Int X Int) 

Recursive resolution: Note that resolving the query l{Int x Int) 
involves applying multiple rules. The current environment does not 
contain the required integer pair It does however contain the integer 
3 and a rule (\{llnt, lint + 1) : {Int} ^ Int x Int\) to compute 
a pair from an integer. Hence, the query is resolved with (3, 4), the 
result of applying the pair-producing rule to 3. 

Polymorphic rules and queries: A^ allows polymoiphic rules. 
For example, the rule 

(|(?a, la) : Va.{a} ^ aXa\) 

can be instantiated to multiple rules of monomorphic types 

{Int} => Int X Int, {Bool} => Bool X Bool, . . . 

Multiple monomorphic queries can be resolved by the same rule. 
The following expression returns ((3, 3), {True, True)): 

implicit {3, True, (\{la, la) : Va.ja} => axa[)} in 
{l{Int X Int), l{Bool x Bool)) 

Polymorphic rules can also be used to resolve polymorphic queries: 

implicit {(|(?Q, la) : 'Va.{a} => axa\)} in 
l{\/a.{a} ^ axa) 

Combining higher-order and polymorphic rules: The rule 

<\{l{{lntxlnt)x{lntxlnt))) : {Int,\/a.{a} => axa} ^ 
{Int X Int) X {Int x Int) \) 

prescribes how to build a pair of integer pairs, inductively from an 
integer value, by consecutively applying the rule of type 

Va.ja} => QXQf 

twice: first to an integer, and again to the result (an integer pair). 
For example, the following expression returns ((3, 3), (3, 3)): 

implicit {3, (|(?a, ?a) : Va.{a} => aXQ[)} in 
l{{Int X Int) X {Int x Int)) 



Locally and lexically scoped rules: Rules can be nested and res- 
olution respects the lexical scope of rules. Consider the following 
program: 



implicit {1} in 
implicit { True, 

in lint 



if IBool then 2 : { Bool } => /ni[) } 



The query lint is not resolved with the integer value 1. Instead the 
rule that returns an integer from a boolean is applied to the boolean 
True, because those two rules can provide an integer value and 
they are nearer to the query. So, the program returns 2 and not 1. 

Overlapping rules: Two rules overlap if their return types inter- 
sect, i.e., when they can both be used to resolve the same query. 
Overlapping rules are allowed in A=i. through nested scoping. The 
nearest matching rule takes priority over other matching rules. For 
example consider the following program: 



implicit {Xx.x : "ia-a 
implicit {Xn.n + 1 : 
i{Int ^ Int)l 



->■ a} in 

Int — ^ Int} in 



In this case Xn.n -\- 1 : Int — s- Int is the lexically nearest match in 
the implicit environment and evaluating this program results in 2. 
However, if we have the following program instead: 

implicit {Xn.n + 1 : Int — ;> /nf } in 
implicit {Xx.x : Va.Q — >■ a} in 
i{Int -^ Int)l 

Then the lexically nearest match is Xx.x-.Wa.a — >■ a and evaluating 
this program results in 1. 

3. The A^ Calculus 

This section formalizes the syntax and type system of A=^. 

3.1 Syntax 

This is the syntax of the calculus: 



(Simple) Types 
Rule Types 
Expressions 



a I Int I Ti 
Va.p => r 

n \ x \ Xx : T.e 



T-2 I P 



ei 62 



?p I (|e : pD I e[f\ \ e with e : p 



Types T are either type variables a, the integer type Int, function 
types Ti — >■ T2 or rule types p. A rule type p = Va.p => r 
is a type scheme with universally quantified variables a and an 
(implicit) context p. This context summarizes the assumed implicit 
environment. Note that we use o to denote an ordered sequence 
oi, . . . , o„ of entities and o to denote a set {oi, . . . , o„}. Such 
ordered sequences and sets can be empty, and we often omit empty 
universal quantifiers and empty contexts from a rule type. The base 
case of rule types is when p is the empty set (Va.{} => r). 

Expressions include integer constants n and the three basic 
typed A-calculus expressions (variables, lambda binders and appli- 
cations). A query ?p queries the implicit environment for a value of 
type p. A rule abstraction (\e : Wa.p => rD builds a rule whose 
type is Va.p => r and whose body is e. 

Without loss of generality we assume that all variables x and 
type variables a in binders are distinct. If not, they can be easily 
renamed apart to be so. 

Note that, unlike System F, our calculus does not have a separate 
A binder for type variables. Instead rule abstractions play a dual 
role in the binding structure: 1) the universal quantification of type 
variables (which binds types), and 2) the context (which binds a 
rule set). This design choice is due to our interpretation of rules 



as logic programming rulefl After all, in the matching process of 
resolution, a rule is applied as a unit. Hence, separating rules into 
more primitive binders (a la System F's type and value binders) 
would only complicate the definition of resolution unnecessarily. 
However, elimination can be modularized into two constructs: type 
application e[f] and rule application e with e : p. 

Using rule abstractions and applications we can build the 
implicit sugar that we have used in Sections[T]and|2] 



implicit e : p in ei 



def 

: T — 



ei 



rl) with e : 



For readability purposes, when we use implicit we omit the 
type annotation r. As we shall see in Section[5]this annotation can 
be automatically inferred. 

For brevity and simplicity reasons, we have kept A^ small. In 
examples we may use additional syntax such as built-in integer 
operators and boolean literals and types. 

3.2 Type System 

Figure [T] presents the static type system of A^. The typing judg- 
ment r I A h e ; r means that expression e has type r under type 
environment F and implicit environment A. The auxiliary resolu- 
tion judgment A hr p expresses that type p is resolvable with 
respect to A. Here, F is the conventional type environment that 
captures type variables; A is the implicit environment, defined as 
a stack of contexts. Figure [T] also presents lookup in the implicit 
environment (A(r)) and in contexts (p{t)). 

We will not discuss the first four rules ((Tyint), (TyVar), 
(TyAbs) and (TyApp)) because they are entirely standard. For now 
we also ignore the gray-shaded conditions in the other rules; they 
are explained in Section [331 

Rule (TyRule) checks a rule abstraction (\e : \/a.p => r[) by 
checking whether the rule's body e actually has the type r under the 
assumed implicit type context p. Rule (Tylnst) instantiates a rule 
type's type variables a with the given types f, and rule (TyRApp) 
instantiates the type context p with expressions of the required rule 
types e : p. Finally, rule (TyQuery) delegates queries directly to the 
resolution rule (TyRes). 

Resolution Principle The underlying principle of resolution in 
A^ originates from resolution in logic. Following the Curry- 
Howard correspondence, we assign to each type a corresponding 
logical interpretation with the (■)^ function: 

Definition 3.1 (Logical Interpretation). 



(n- 

(yd.p - 



a 
Int'' 

■r2)t 



a 
Int'' 



yd\ /\ pt 



Here, type variables a map to propositional variables a^ and the 
primitive type Int maps to the propositional constant Int'' . Unlike 
CuiTy-Howard, we do not map function types to logical implica- 
tions; we deliberately restrict our implicational reasoning to rule 
types. So, instead we also map the function arrow to an uninter- 
preted higher-order predicate — >-^. Finally, as already indicated, we 
map rule types to logical implications. 

Resolution in A=^ then corresponds to checking entailment of 
the logical interpretation. We postulate this property as a theorem 
that constrains the design of resolution. 

Theorem 3.1 (Resolution Specification). 

If A \-r p, tlien A^ \= pt. 



In Prolog these are not separated either. 



Type Environments F ::= ■ | r;a: : r 

Implicit Environments A ::= ■ | A;p 



r 1 Ahe 


r 




r\ Ah n: Int 




(Tyint) 






(TyVar) 






(X : r) 6 r 
r\A\-x:T 




(TyAbs) 






r;x : Ti A h e : r2 




r 


1 A h Ax : ri .e : Ti — S> r2 




/•TirAnr^^ 


r 


lAh 


ei : T2 — >■ ri F A h 62 


T2 



(TyRule) 



(Tylnst) 



(TyRApp) 



(TyQuery) 



Ahr p 



(TyRes) 



F I A h ei 62 : Ti 

p = Va.p =► T unambiguous(p) 

F|A;p|-e:r an/to(F, A) = 
r\Ah(le:p\):p 

F I A h e : Va.p => t 
F I A h ep] ; [aM>T](p => r) 

F I A h e : p=> T 

F I A I- ej : Pi (Vej : pj g FTp) 

F I A h (e with eTp) : r 

A hr p unambiguous(p) 
F j A |-?p : p 



A{t) =p'^t 

A hr Pi (Vpi & p' - p) 

A \-r "ia.p =^ T 



A(r) = p 



p(t) = p 



p(r> 


= p no.overia 


p(p,t) 




(A;p)(r>=p 






p(r) = ± A(r> = 


= P 




(A;p)(r>=p 




pep 


p = \/d'.i5' =>t' 


er'=T 



p(r> 



Figure 1. Type System 



Resolution for Simple Types The step from the logical interpre- 
tation to the (TyRes) rule in Figure[T]is non-trivial. So, let us first 
look at a simpler incarnation. What does resolution look like for 
simple types r like Intl 

A(r) = p' ^T 
(SimpleRes) A hr Pi {Vpi G p') 



Ahr r 

First, it looks up a matching rule type in the implicit environment by 
means of the lookup function A(r) defined in Fig.Q] This partial 
function respects the nested scopes: it first looks in the topmost 
context of the implicit environment, and, only if it does not find a 
matching rule, does it descend. Within an environment context, the 
lookup function looks for a rule type whose right-hand side r' can 



be instantiated to the queried r using a matching unifier 6. This rule 
type is then returned in instantiated form. 

The matching expresses that the looked-up rule produces a value 
of the required type. To do so, the looked-up rule may itself require 
other implicit values. This requirement is captured in the context 
p', which must be resolved recursively. Hence, the resolution rule 
is itself a recursive rule. When the context p of the looked-up rule 
is empty, a base case of the recursion has been reached. 
Example Consider this query for a tuple of integers: 

Int;\/a.{a} => q x a hr Int x Int 

Lookup yields the second rule, which produces a tuple, instantiated 
to {Int} => Int X Int with matching substitution S = [a n- Int]. 
In order to produce a tuple, the rule requires a value of the compo- 
nent type. Hence, resolution proceeds by recursively querying for 
Int. Now lookup yields the first rule, which produces an integer, 
with empty matching substitution and no further requirements. 

Resolution for Rule Types So far, so good. Apart from allowing 
any types, recursive querying for simple types is quite similar 
to recursive type class resolution, and A^ carefully captures the 
expected behavior. However, what is distinctly novel in A=>, is that 
it also provides resolution of rule types, which requires a markedly 
different treatment. 



(RuleRes) 



A(r) 



A hr Va.p ^ r 

Here we retrieve a whole rule from the environment, including its 
context. Resolution again performs a lookup based on a matching 
right-hand side r, but subsequently also matches the context with 
the one that is queried. No recursive resolution takes place. 
Example Consider a variant of the above query: 

/ni;Va.{a} => a x a hr {Int} => Int x Int 

Again lookup yields the second rule, instantiated to {Int} => 
Int X Int. The context {Int} of this mle matches the context of 
the queried rule. Hence, the query is resolved without recursive 
resolution. 

Unified Resolution The feat that our actual resolution rule (TyRes) 
accomplishes is to unify these seemingly disparate forms of resolu- 
tion into one single inference rule. In fact, both (SimpleRes) and 
(RuleRes) are special cases of (TyRes), which provides some ad- 
ditional expressiveness in the form of partial resolution (explained 
below). 

The first hurdle for (TyRes) is that types r and rule types p are 
different syntactic categories. Judging from its definition, (TyRes) 
only covers rule types. How do we get it to treat simple types 
then? Just promote the simple type r to its corresponding rule 
type V.{} => r and (TyRes) will do what we expect for simple 
types, including recursive resolution. At the same time, it still 
matches proper rule types exactly, without recursion, when that is 
appropriate. 

Choosing the right treatment for the context is the second hur- 
dle. This part is managed by recursively resolving p' — p. In the 
case of promoted simple types, p is empty, and the whole of p' is 
recursively solved; which is exactly what we want. In the case p' 
matches p, no recursive resolution takes place. Again this perfectly 
con'esponds to what we have set out above for proper rule types. 
However, there is a third case, where p' — p is a non-empty proper 
subset of p . We call this situation, where part of the retrieved rule's 
context is recursively resolved and part is not, partial resolution. 
Example Here is another query variant: 

Bool\'^a.{Bool,OL} => a x a hr {Int} => Int x Int 

The first lookup yields the second rule, instantiated to {Bool, Int} => 
Int X Int, which almost matches the queried rule type. Only Bool 



in the context is unwelcome, so it is eliminated through a recur- 
sive resolution step. Fortunately, the first rule in the environment is 
available for that. 

Semantic Resolution Within the confines of the semantic con- 
straint of Theorem 13. li the rule (TyRes) implements a rather syn- 
tactic notion of resolution. In contrast, a fully semantic definition 
of resolution would coincide exactly with the semantic constraint 
and satisfy 

Ahr p iff At ^ pt 

For instance, it would allow to resolve 

Char; Char => Int; Bool => Int hr Int 

In this example, resolution gets stuck using the topmost rule in the 
environment. However, by using the next one down, the query can 
be resolved. The problem with supporting this semantic notion of 
resolution is that it requires backtracking. Because backtracking 
easily becomes a performance problem and because it is mentally 
hard to reason about for the programmer, we have decided against 
it. 

We have considered another definition of resolution, that avoids 
backtracking but is closer to the semantic notion: 

A(r) =p^T 

A,p\-rPi jvpiep') 

A \-r yS.p ^ r 

This rule extends the environment A with the queried rule type's 
context p for recursive resolution of the matching rule type's con- 
text p' . It resolves the following query that rule (TyRes) does not: 

Char; Char => Int; Bool => Int hr Char => Int 

However, we prefer our more syntactic definition of resolution, 
rule (TyRes), because it is much simpler: the environment does 
not grow recursively, but stays the same throughout the whole 
recursive resolution. We believe that this way it is more manageable 
for the programmer to perform resolution mentally. Moreover, the 
invariant environment in rule (TyRes) is much easier for deciding 
termination. 

3.3 Additional Type System Conditions 

The gray-shaded conditions in the type system are to check lookup 
errors (no_overlap) and ambiguous instantiations (unambiguous). 

Avoiding Lookup Errors To prevent lookup failures, we have to 
check for two situations: 

• A lookup has no matching rule in the environment. 

• A lookup has multiple matching rules which have different rule 
types but can yield values of the same type (overlapping rules). 

The former condition is directly captured in the definition of lookup 
among a set of rule types. The latter condition is captured in the 
no_overlap property, which is defined as: 

no_overlap({pi, . . . ,p„},r) = 

Vi,j. Pi = VcTi.pi => Ti A 39i.9iTi = T 

A pj = Voj.pj ^ Tj A ^ej.OjTj = r 

Avoiding Ambiguous Instantiations We avoid ambiguous instan- 
tiations in the same way as Haskell does: all quantified type vari- 
ables (a) in a rule type (VcJ.p => r) must occur in r. We use the 
unambiguous condition to check in (TyRule) and (TyQuery): 

unambiguous(VQ.p => r) = 5 C ftv{T) 

A Vpi G p.unambiguous(pi). 



If there is a quantified type variable not in type r, the type may 
yield ambiguous instantiations (e.g. Va.{a} => Int). 

4. Type-Directed Translation to System F 

In this section we define the dynamic semantics of A=^ in terms of 
System F's dynamic semantics, by means of a type directed trans- 
lation. This translation turns implicit contexts into explicit parame- 
ters and statically resolves all queries, much like Wadler and Blott's 
dictionary passing translation for type classes 11421 . The advantage 
of this approach is that we simultaneously provide a meaning to 
well-typed A^ programs and an effective implementation that re- 
solves all queries statically. 

4.1 Type-Directed Translation 

Figure|2]presents the translation rules that convert A^ expressions 
into ones of System F extended with the integer and unit types. This 
figure essentially extends Figure [T] with the necessary information 
for the translation, but for readability we have omitted the earlier 
gray-shaded conditions. 

The syntax of System F is as follows: 

Types T ::= a\T ^T\ \fa.T \ Int \ () 

Expressions E ::= x \ \{x : T).E \ E E \ Aa.E \ E T \ n \ {) 

The main translation judgment is 

r I A h e : r --» S, 

which states that the translation of A=^ expression e with type r 
is System F expression E, with respect to type environment F and 
translation environment A. The translation environment A relates 
each rule type in the earlier implicit environment to a System F 
variable x; this variable serves as value-level explicit evidence for 
the implicit rule. Lookup in the translation environment is defined 
similarly to lookup in the type environment, except that the lookup 
now returns a pair of a rule type and an evidence variable. 

Figure|2]also defines the type translation function | ■ | from A=^ 
types r to System F types T. In order to obtain a unique translation 
of types, we assume that the types in a context are lexicographically 
ordered. 

Variables, lambda abstractions and applications are translated 
straightforwardly. Queries are translated by rule (TrQuery) using 
the auxiliary resolution judgment hr, defined by rule (TrRes). Note 
that rule (TrRes) performs the same process that rule (TyRes) 
performs in the type system except that it additionally collects 
evidence variables. 

Rule (TrRule) translates rule abstractions to explicit type and 
value abstractions in System F, and rule (Trinst) translates instan- 
tiation to type application. Finally, rule (TrRApp) translates rule 
application to application in System F 
Example We have that: 

• I ■ h (|(?a, la) : \la.{a] ^ a X q[) 

-^ Aa.A(x- : a).{x, x) 

and also: 

{Int : xi), (ya.{a} => a X a : X2) \~r Int x Int 

-^ X2 Int xi 

For brevity, Figure|2]omits the case where the context of a rule type 
is empty. To properly handle empty contexts, the translation of rule 
type should include |{} => t\ = () — >■ \t\ and the translation 
rules (TrRule), (TrRApp) and (TrRes) should be extended in the 
obvious way. 

Tlieorem 4.1 (Type-preserving translation). Let ebe a A^ expres- 
sion, T be a type and E be a System F expression. If-\-\-e:T'^ 
E, then ■ 'r E : Irl. 
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Figure 2. Type-directed Translation to System F 



interface Eq a = {eq : a — >■ o — > _Boo/} 

let (=) : Vo. {-Eg a} ^ a — )■ q — > Booi = e? ? in 

let eqlnti : Eq Int = Eq {eq = primEqInt } in 

let eqintz ■ Eq Int = Eq {eq = Xx y.isEven x A isEven y} in 

let eqBool : Eq Bool = Eq {eq = priniEqBool} in 

let eqPair : Va /3. {Eq a, Eq /3} => Eq {a, /3) = 

Eq {eq = Xx y.fst x = fst y A snd x = snd y} in 
let pi ; {Int, Bool) = (4, True) in 
let p2 ■■ {Int, Bool) = (8, True) in 
implicit {eqlnti , eqBool, eqPair} in 

(pi = p2, implicit {eqintz } in pi = P2) 

Figure 3. Encoding the Equality Type Class 

Proof. (Sketch) We first provqj the more general lemma "if F | 
A h e : r ~* _E, then |r|, |A| h _B : |r|" by induction on the 
derivation of translation. Then, the theorem is trivially proved by 
it. D 

4.2 Dynamic Semantics 

Finally, we define the dynamic semantics of A^ as the composition 
of the type-directed translation and System F's dynamic semantics. 
Following Siek's notation 1341 . this dynamic semantics is: 

eval{e) — V where ■ \ ■\- e : t -^ E and E — >■* V 

with -^* the reflexive, transitive closure of System F's standard 
single-step call-by-value reduction relation. 

Now we can state the conventional type safety theorem for A^ : 

Theorem 4.2 (Type Safety). If ■ \ ■ \- e : r, then eval{e) = V for 
some System F value V. 



The proof follows trivially from Theorem 14. II 

5. Source Languages and Implicit Instantiation 

Languages like Haskell and Scala provide a lot more programmer 
convenience than A=^ (which is a low level core language) because 
of higher-level GP constructs, interfaces and implicit instantiation. 
This section illustrates how to build a simple source language on 
top of A=^ to add the expected convenience. We should note that 
unlike Haskell this language supports local and nested scoping, and 
unlike both Haskell and Scala it supports higher-order rules. We 
present the type-directed translation from the source to A^. 

5.1 Type-directed Translation to A^ 

The full syntax is presented in Figure |4] Its use is illustrated in 
the program of Figure|3] which comprises an encoding of Haskell's 
equality type class Eq. The example shows that the source language 
features a simple type of interface / T (basically records), which 
are used to encode simple forms of type classes. Note that we 
follow Haskell's conventions for records: field names u are unique 
and they are modeled as regular functions taking a record as the 
first argument. So a field u with type T in an interface declaration 
/ a actually has type Va.{} ^ I a ^- T. There are also other 
conventional programming constructs (such as let expressions, 
lambdas and primitive types). 

Unlike the core language, we strongly differentiate between 
simple types T and type schemes a in order to facilitate type in- 
ference. Moreover, as the source language provides implicit rather 
than explicit type instantiation, the order of type variables in a 
quantifier is no longer relevant. Hence, they are represented by a set 
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Figure 4. Syntax of Source Language 



(Va). We also distinguish simply typed variables x from let-bound 
variables u with polymorphic type a. 

Figure |5]presents the type-directed translation G h E : T -^^ e 
of source language expressions E of type T to core expressions e, 
with respect to type environment G. The type environment collects 
both simply and polymorphic variable typings. The connection 
between source types T and a on the one hand and core types r 
and p on the other hand is captured in the auxiliary function |-|. 
Note that this function imposes a canonical ordering a on the set of 
quantifier variables a (based on their precedence in the left-to-right 
prefix traversal of the quantified type term). For the translation of 
records, we assume that A^ is extended likewise with records. 

let and let-bound variables The rule (TyLet) in Figure|5]shows 
the type-directed translation for let expressions. This translation 
binds the variable u using a regular lambda abstraction in an ex- 
pression 62, which is the result of the translation of the body of the 
let construct (E2). Then it applies that abstraction to a rule whose 
rule type is just the corresponding (translated) type of the definition 
((Ti), and whose body is the translation of the expression Ei. 

The source language provides convenience to the user by infer- 
ring type arguments and implicit values automatically. This infer- 
ence happens in rule (TyLVar), i.e., the use of let-bound variables. 
That rule recovers the type scheme of variable u from the environ- 
ment G. Then it instantiates the type scheme and fires the necessary 
queries to resolve the context. 

Queries The source language also includes a query operator (?). 
Unlike A=^ this query operator does not explicitly state the type; 
that information is provided implicitly through type inference. For 
example, instead of using pi = p2 in Figure |5] we could have 
directly used the field eg as follows: 

eg ? pi P2 

When used in this way, the query acts like a Coq placeholder (_), 
which similarly instructs Coq to automatically infer a value. 

The translation of source language queries, given by the rule 
(TylVar), is fairly straightforward. To simplify type-inference, the 
query is limited to types, and does not support partial resolution (al- 
though other designs with more powerful queries are possible). In 
the translated code the query is combined with a rule instantiation 
and application in order to eliminate the empty rule set. 
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Figure 5. Type-directed Encoding of Source Language in A= 



Implicit scoping The implicit construct, which has been al- 
ready informally introduced in Section [T] is the core scoping con- 
struct of the source language. It is used in our example to first in- 
troduce definitions in the implicit environment ( eqlnti , eqBool and 
eqPair) available at the expression 

(pi = p2, implicit {eqlnt2 } in pi = P2) 

Within this expression there is a second occurrence of implicit, 
which introduces an overlapping rule (eqintz) that takes priority 
over eqlnti for the subexpression pi = P2 . 

The translation rule (TyImp) of implicit into A=^ also exploits 
type-information to avoid redundant type annotations. For example, 
it is not necessary to annotate the let-bound variables used in 
the rule set u because that information can be recovered from the 
environment G. 

Higher-order rules and implicit instantiation for any type The 

following example illustrates higher-order rules and implicit instan- 
tiation working for any type in the source language. 



let show : Va. {a — >■ String} => a ^- String = ? in 
let showlnt : Int -^ String = . . . in 
let comma : Va. {a — )> String} => [q] -t> String = . . . in 
let space : Va. {a — >■ String } => [a] — >■ String — . . . in 
let o : {7nt — >■ String, {Int -^ String} => [Jni] — >■ String} 

=> String — show [1, 2, 3] in 
implicit showlnt in 
(implicit comma in o, implicit space in o) 

For brevity, we have omitted the implementations of showlnt, 
comma and space; but showlnt renders an Int as a String 
in the conventional way, while comma and space provide two 
ways for rendering lists. Evaluation of the expression yields 
("1,2,3", "1 2 3"). Thanks to the implicit rule parameters, the 
contexts of the two calls to o control how the lists are rendered. 

This example differs from that in Figure |3] in that instead of 
using a nominal interface type like Eq, it uses standard functions 
to model a simple concept for pretty printing values. The use of 
functions as implicit values leads to a programming style akin to 
structural matching of concepts, since only the type of the function 
matters for resolution. 

5.2 Extensions 

The goal of our work is to present a minimal and general framework 
for implicits. As such we have avoided making assumptions about 
extensions that would be useful for some languages, but not others. 
In this section we briefly discuss some extensions that would be 
useful in the context of particular languages and the implications 
that they would have in our framework. 

Full-blown Concepts The most noticeable feature that was not 
discussed is a full-blown notion of concepts. One reason not to 
commit to a particular notion of concepts is that there is no general 
agreement on what the right notion of concepts is. For example, 
following Haskell type classes, the C++Ox concept proposal 1111 
is based on a nominal approach with explicit concept refinement, 
while Stroustrup favors a structural approach with implicit concept 
refinement because that would be more familiar to C++ program- 
mers 1371 . Moreover, various other proposals for GP mechanisms 
have their own notion of interface: Scala uses standard 00 hierar- 
chies; Dreyer et al. use ML-modules |[8]; and in dependently typed 
systems (dependent) record types are used II36| |5|. 

An advantage of A^ is that no particular notion of interface is 
imposed on source language designers. Instead, language design- 
ers are free to use the one they prefer In our source language, for 
simplicity, we opted to add a very simple (and limited) type of in- 
terface. But existing language designs ||29| [8l [361151 offer evidence 
that more sophisticated types of interfaces, including some form of 
refinement or associated types, can be built on top of A^ . 

Type Constructor Polymorphism and Higher-order Rules Type 
constructor polymorphism is an advanced, but highly powerful GP 
feature available in Haskell and Scala, among others. It allows 
abstracting container types like List and Tree with a type variable 
/; and applying the abstracted container type to different element 
types, e.g., / Int and / Bool. 

This type constructor polymorhism leads to a need for higher- 
order niles: rules for containers of elements that depend on rules for 
the elements. The instance for showing values of type Perfect f a 
in Section[T] is a typical example of this need. 

Extending A=^ with type constructor polymorphism is not hard. 
Basically, we need to add a kind system and move from a System F 
like language to System F^i like language. 

Subtyping Languages like Scala or C++ have subtyping. Subtyp- 
ing would require significant adaptations to A^. Essentially, in- 
stead of targetting System F, we would have to target a version of 



System F with subtyping. In addition, the notion of matching in the 
lookup function A(t) would have to be adjusted, as well as the 
nojjverlap condition. While subtyping is a useful feature, some 
language designs do not support it because it makes the system 
more complex and interferes with type-inference. 

Type-inference Languages without subtyping (like Haskell or 
ML) make it easier to support better type-inference. Since we 
do not use subtyping, it is possible to improve support for type- 
inference in our source language. In particular, we currently require 
a type annotation for let expressions, but it should be possible to 
make that annotation optional, by building on existing work for the 
GHC Haskell compiler Ii32ii4l1 . 

6. Related Work 

Throughout the paper we have already discussed a lot of related 
work. In what follows, we offer a more detailed technical compar- 
ison of A=^ versus System F^ and Scala implicits, which are the 
closest to our work. Then we discuss the relation with other work 
in the literature. 

System. F Generally speaking our calculus is more primitive 
and general than System F . In contrast to A=i., System F has 
both a notion of concepts and implicit instantiation of concept^. 
This has the advantage that language designers can just reuse that 
infrastructure, instead of having to implement it. The language 
G 1351 is based on System F and it makes good use of these 
built-in mechanisms. However, System F also imposes impor- 
tant design choices. Firstly it forces the language designer to use 
the notion of concepts that is built-in to System F . In contrast A=^ 
offers a freedom of choice (see also the discussion in Section [J!2t . 
Secondly, fixing implicit instantiation in the core prevents useful al- 
ternatives. For example, Scala and several other systems do provide 
implicit instantiation by default, but also offer the option of explicit 
instantiation, which is useful to resolve ambiguities |29lll8| [6l[8l. 
This cannot be modeled on top of System F^ , because explicit 
instantiation is not available. In contrast, by taking explicit instan- 
tiation (rule application) as a core feature, A=i. can serve as a target 
for languages that offer both styles of instantiation. 

There are also important differences in terms of scoping and 
resolution of rules. System F only formalizes a very simple 
type of resolution, which does not support recursive resolution. 
Furthermore, scoping is less fine-grained than in A^ . For example. 
System F'^ requires a built-in construct for model expressions, 
but in A=^ implicit (which plays a similar role) is just syntactic 
sugar on top of more primitive constructs. 

Scala Implicits Scala implicits are integrated in a full-blown lan- 
guage, but they have only been informally described in the liter- 
ature 12911271 . Our calculus aims at providing a formal model of 
implicits, but there are some noteworthy differences between A^ 
and Scala implicits. In contrast to A=^, Scala has subtyping. As dis- 
cussed in Section [5!2l subtvping would require some adaptations to 
our calculus. In Scala, nested scoping can only happen through sub- 
classing and the rules for resolution in the presence of overlapping 
instances are quite ad-hoc. Furthermore, Scala has no (first-class) 
rule abstractions. Rather, implicit arguments can only be used in 
definitions. In contrast A=i. provides a more general and disciplined 
account of scoping for rules. 

Type Classes Obviously, the original work on type classes II42I 
and the framework of qualified types |I5| around it has greatly 
influenced our own work, as well as that of System F and Scala. 



' Note that instantiation of type variables is still explicit. 



There is a lot of work on Haskell type classes in the literature. 
Notably, there have been some proposals for addressing the limita- 
tions that arise from global scoping ||18l l6l. However in those de- 
signs, type classes are still second-class and resolution only works 
for type classes. The GHC Haskell compiler supports overlapping 
instances ||17| . that live in the same global scope. This allows some 
relief for the lack of local scoping. A lot of recent work on type 
classes is focused on increasingly more powerful "type class" in- 
terfaces. Functional dependencies 1161 , associated types (4]|3) and 
type families (31| are all examples of this trend. This line of work 
is orthogonal to our work. 

Other Languages and Systems Modular type classes (H are a 
language design that uses ML-modules to model type classes. The 
main novelty of this design is that, in addition to explicit instantia- 
tion of modules, implicit instantiation is also supported. In contrast 
to A=>, implicit instantiation is limited to modules and, although 
local scoping is allowed, it cannot be nested. 

Instance arguments (5] are an Agda extension that is closely re- 
lated to implicits. However, unlike most GP mechanisms, implicit 
rules are not declared explicitly. Furthermore resolution is limited 
in its expressive power, to avoid introducing a different computa- 
tional model in Agda. This design differs significantly from A^;., 
where resolution is very expressive and the scoping mechanisms 
allow explicit rule declarations. 

Implicit parameters 1221 are a Haskell extension that allows 
named arguments to be passed implicitly. Implicit parameters are 
resolved by name, not by type and there is no recursive resolution. 

GP and Logic Programming The connection between Haskell 
type classes and Prolog is folklore. Neubauer et. al. 0251 also 
explore the connection with Functional Logic Programming and 
consider different evaluation strategies to deal with overlapping 
rules. With Constraint Handling Rules, Stuckey and Sulzmann 1381 
use Constraint Logic Programming to implement type classes. 



7. Conclusion 

Our main contribution is the development of the implicit calculus 
A^. This calculus isolates and formalizes the key ideas of Scala 
implicits and provides a simple model for language designers inter- 
ested in developing similar mechanisms for their own languages. 
In addition, A=^ supports higher-order rules and partial resolution, 
which add considerable expressiveness to the calculus. 

Implicits provide an interesting alternative to conventional GP 
mechanisms like type classes or concepts. By decoupling resolution 
from a particular type of interfaces, implicits make resolution more 
powerful and general. Furthermore, this decoupling has other ben- 
efits too. For example, by modeling concept interfaces as conven- 
tional types, those interfaces can be abstracted as any other types, 
avoiding the issue of second class interfaces that arise with type 
classes or concepts. 

Ultimately, all the expressiveness offered by A^ offers a wide- 
range of possibilities for new generic programming applications. 
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which loops, using alternatively the first and second rule in the 
implicit environment. 

The problem of non-termination has been widely studied in the 
context of Haskell's type classes, and a set of modular syntactic 
restrictions has been imposed on type class instances to avoid non- 
termination 1391 . Adapting these restrictions to our setting, we 
obtain the following termination condition. 

Definition A.l (Termination Condition). An implicit environment 
A satisfies the condition, denoted term(A), iff term(p) for every 
p — (ya.p => r) £ rfom(A), where: 

term{p) <4- 0CCa(r') ^ ocCa(r) 

(V(Vq'.p' => t') epyad ,ftv(r, r,)) \ a) 
A |ril < \r\ {Wi e p) 
A term{p') (Vp' G p) 
where 



OCCa{Int) 


= 





OCCa{a) 


= 


1 


OCCa{a') 


= 


{af^a 


OCCa{Tl -^ T2) 


= 


OCCa{Tl) + 0CCa{T2) 


ocCcilya.p => r) 


= 


OCCa{T) + ^ OCCa{p) 

pep 


\Int\ 


= 


1 


\a\ 


= 


1 


\ri -^ T2\ 


= 


l + lnl + |r2| 


IVa.p => r\ 


^ 


i + kl+I]|p|- 

pep 


. Proofs 







Throughout the proofs we refer to the type system rules of System 
F listed in Figure |6] 



Lemma B.l. If 






r|Ahe -.T-^E 


then 






|r|,|A| KB : |r| 



Proof. By structural induction on the expression and corresponding 
inference rule. 

(Trint) F] A h n : Int -^ n 

It follows trivially from (F-Int) that 

IFLIAI h n: Int 



(TrVar) FjA h x : t ■ 



(F-Int) 
(F-Var) 

(F-Abs) 

(F-App) 

(F-TApp) 
(F-TAbs) 



r\- n: Int 

{x : T) £ r 
r\- x:T 

r,x:Ti\- E -.Ti 
r\- Xx -.Ti.E-.Ti -^T2 

rh Ei:T2^Ti 
ThEi-.Ti 



Th El 


E2 :Ti 


T\- E 


: Wa.Ti 


r\- ETi : 


[a ^ T{\T2 


r\- E -.T 


a^ftv{r) 



r h Aa.E : ya.T 



Figure 6. System F Type System 

It follows from (TrVar) that 

(x : r) G r 
Based on the definition of | ■ | it follows 

{x:\r\)e\r\ 
Thus we have by (F-Var) that 

|r|,|A|hx:|r| 

(TrAbs) r|A h Ax : n.e : n ^ T2 -^ \x : \ti\.E 

It follows from (TrAbs) that 

r;a;:ri|AI-e:T2~>-E 
and by the indution hypothesis that 

|r|,x: !ri|,|A|h£: \t2\ 

As all variables are renamed unique, it is easy to verify that this 
also holds: 

|r|,|A|,x:|ri|hi5:|r2| 

Hence, by (F-Abs) we have 

|r|,|A|hAx: \n\.E: In ^ ra] 

(TrApp) r\A\- eie2:Ti'-^ E1E2 

By the induction hypothesis, we have: 

|r],|A]h£;i: Ir^^nl 
and 

\r\,\A\hE2:\r2\ 
Then it follows by (F-App) that 

\r\,\A\hEiE2: Inl 



(TrQuory) r| A |-?p : p -^ E 

From (TrQuery) we have 

A^ p-^ E 
Based on Lemma lBT2l we then know 

\A\^E:\p\ 
Hence, because all variables are unique 
\n\A\^E:\p\ 

(TrRule) T\A ^ (\e : p\) : p -^ Aa.X{x : \p\).E 

Based on (TrRule) and the induction hypothesis, we have 

lr|,|A|,f:|^hi5:|r| 
where 

p = Va.p => T 
Thus, based on (F-Abs) we have 

|rl,lA|hA(f :|^).S:|pi|^...^|p„|^|rl 
or, using the definition of | ■ | 

|r|,|A|hA(f:|^).£:|p^rl 
Moreover, because of (TrRule), we know 

anftv{r,A) = 

and hence 

Qn/to(|r|,|A|) = 

So, finally, we may conclude from (F-TAbs) that 

|r|, |A| h AQ.A(f : \p\).E : Vq.|p ^ r\ 
and again with | • | 

|r|, |A| h Aq.A(x : \p\).E : \ia.p => t\ 



(Trlnst) r|A h e[T\ : [a ^ t\{p ^ t) -^ E |f| 

By (Trlnst) and the induction hypothesis, it follows that 

|r|,|A| h£: |Va.p^r| 
From which we have by definition of | • | 

|r|,|A| |-S:Va.|p^r| 
It follows from (F-TApp) that 

|r|,|A|hi5|r|:[Q^|f|]|p^r| 
which is easily seen to be equal to 

|r|,|A| h E\t\: \[a^T\{p^T)\ 



(TrRApp) rjA h ewitheTp : r-^ S_B 

From (TrApp) and the induction hypothesis we have: 

|r|,|A| |-£: |p^r| 
and 

|r|,|A| h e, ■ |p,|(Vi) 



Hence, base on the definition of | ■ | the first of these means 

|r|,|A| ^ E: \pi\ -^ ...^ \pn\ -^ \t\ 
Hence, based on (F-App) we know 

|r|,|A| ^ EE : \t\ 

D 



Lemma B.2. If 






Ah p-^ E 


then 






\A\hE:\p\ 



Proof. By induction on the derivation. 
From (TrRes) we have 

A \- p -^ Aa.\{x : \p\).{EE) 
where 

p — \/a..p => r 
Also from (TrRes) and the induction hypothesis, we have 

\A\hE,:\pi\ (prep-p) 
Also from (TrRes) and Lemma lB3] we have 
\A\h E: \p ^t\ 

Assembling these parts using (F-App), (F-Abs) and (F-TAbs) 
we come to 



|A| h Aq.A(x : \p\).{EE) 



D 



Lemma B.3. // 






A(t) = p^t ■ E 


then 






\A\hE:\p^T\ 



Proof. This follows trivially from Lemma IR41 D 



Lemma B.4. If 






p : x{t) — p ^ t : E 


then 






\p : x\\- E : \p ^ t\ 



Proof. From the definintion of lookup we know that iff 

p : x{t) — dp ^ T : x\f\ 
then 

[p : x) G pTx 
Hence, it trivially follows that 

(x : Ip!) e \pTx\ 
Hence, from (F-Var) we have that 

jpT^I h X : \p\ 
Following the definition of | ■ | we also know 

\p : x\ h X : 'ia.\p => r | 
So 

\-pTx\hx\ts\:\e{p' ^t')\ 
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